COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\input memo.tex[let,jmc]
C00008 00003	\smallskip\centerline{Copyright \copyright\ \number\year\ by John McCarthy}
C00009 00004
C00014 ENDMK
C⊗;
\input memo.tex[let,jmc]
\title{Notes on Improving Lisp}
%lisp[w87,jmc]		Improving Lisp

	This is an expanded version of remarks made at the ANSI
Common Lisp Standardization meeting held in Palo Alto, California
in March 1987.

	I understand that there is considerable tension between the
goal of standardizing Common Lisp and the idea, prominent in Europe,
that major improvements should be made in the course of creating
an international standard.
I agree with the idea that Common Lisp should be standardized
as a consolidation of existing practice and that innovations should
be avoided in this process.  My experience with the Algol 60 meetings
led me to the opinion that innovation and standardization do not mix
well.  The trading involved in compromising interests in existing
ways of doing things is only too compatible with what might be called
implicit academic log rolling.  ``I'll agree that your new idea is great if
you'll agree with mine.''  The result is an unimplementable monstrosity.

	  The enormous effort that has already been put into making
a standard Lisp needs only a small amount of consolidation, but I
suppose that this will still involve a very large amount of work.
The standardization process has its costs.  Some good ideas entirely
compatible with how Common Lisp is developing will be ruled out on
the grounds that they aren't present in existing implementations of
Lisp.  I must admit being disappointed that my proposals of a few years
ago for including some kind of arbitrary precision floating point numbers,
exemplified by MACSYMA's ``big floats'' got nowhere.  I thought it would
supplement the existing BIGNUMs and make Lisp really suitable for
numerical computations in pure mathematics.

	However, the ideas of Lisp have not reached a final form, and
there is plenty of room for innovation.  New ideas appear all the time,
and Scheme, T, Tao and Seus all have ideas that are improvements over
those embodied in Common Lisp.  Someday it will be time to combine
the best of them in a new language that will compete with Common
Lisp and hopefully displace it.  The main proper vehicle for advancing
new ideas is individual and small group research and the
the publication of the results and their preentation at
conferences, e.g. the biennial Lisp conferences sponsored by ACM.

	Perhaps there is room for yet another medium for advancing
improvements to Lisp.  I have in mind a Lisp improvement conference,
the object of which is presentation of ideas of a variety of magnitudes,
ranging from modifications of individual functions to advocacy of
complete new systems but with the emphasis on features rather than
complete systems.  The idea of putting big floats into the language
itself would be in order at such a conference.

	Another important direction for improving the utility of Lisp
is making a good library.  At some stage of the Common Lisp meetings,
there was talk of Yellow Pages.  The ball was dropped, and I fear it
was dropped at Stanford.  The library might well be modelled on the
LINPACK and EISPACK libraries for numerical analysis maintained at
Argonne National Laboratories with both the catalog and the programs
themselves consultable via network.

	In this connection, at some time it might be worthwhile for
the Common Lisp standardizers to consider the standardization of
some function names and descriptions of some Lisp functions that are
not required for all implementations of Common Lisp.  The idea is
that whoever implements these functions, whether a supplier of
Common Lisp or a user should use these function names and order
of arguments in order to make his main program more portable
and combinable with other programs.
\smallskip\centerline{Copyright \copyright\ \number\year\ by John McCarthy}
\smallskip\noindent{This draft of LISP.TEX[W87,JMC] TEXed on \jmcdate\ at \theTime}
\vfill\eject\end